Management and Governance for Groups
Overview
Group Management in EmpowerID encompasses a broad and powerful set of capabilities that enable organizations to effectively administer group resources throughout their lifecycle. These capabilities are not limited to just adding or removing members—they span a comprehensive set of administrative functions that support onboarding and offboarding of groups, ownership and eligibility configuration, RBAC policy assignments, group nesting, activity auditing, and integration with self-service access through the IAM Shop.
In EmpowerID, groups are treated as protected resources that can be centrally governed while allowing delegated administration by business users. This is made possible by EmpowerID's role-based access control (RBAC) model, which distinguishes between different types of ownership: Responsible Party, who is the accountable business owner, and Access Managers, who are users or roles granted administrative permissions over a group. These ownership relationships drive visibility, access delegation, and policy enforcement across the system.
Group management tasks can be performed through two primary interfaces:
-
Resource Admin Interface: Designed for non-technical or semi-technical users, this interface provides a streamlined experience with guided workflows for managing groups. It supports delegated administration by resource owners and presents only the options relevant to a user's access rights.
-
Classic Admin Interface: Intended for system administrators and technical users, this interface offers a more granular and data-rich view of group configuration. It allows direct manipulation of group attributes, access policies, RBAC and PBAC assignments, dynamic membership rules, eligibility configurations, and more.
These interfaces are not just cosmetic variations—they reflect EmpowerID's design philosophy of tailoring user experience to technical proficiency and role responsibility. For example, while a delegated owner may use the Resource Admin interface to update membership or assign eligibility, a technical administrator might use the Classic Admin interface to edit extension attributes, apply advanced RBAC policies, or investigate risk violations and audit logs.
EmpowerID also leverages wizard-based workflows to guide users through common group management tasks. These low-code/no-code workflows can be customized by administrators to control which parameters are required, what options are shown, and what behaviors are triggered during execution. This allows organizations to enforce naming conventions, policy standards, and compliance requirements consistently across all managed groups.
Through this training module, you’ll learn how to manage groups using both interfaces, understand the governance models that control group access and visibility, and explore how workflows, policies, and role-based permissions combine to deliver secure and efficient group administration in EmpowerID.
Group Management Functions
Group management in EmpowerID goes far beyond basic add/remove membership operations. It is a comprehensive administrative process that supports both lifecycle operations and granular access control. EmpowerID treats groups as protected resources, enabling full governance of their configuration, membership, visibility, and eligibility for access.
At its core, group management encompasses:
-
Onboarding (Creation) and Offboarding (Deletion): EmpowerID supports the creation of new groups through a workflow-driven process called Onboard Group. This guided workflow walks the user through steps such as selecting the target system (e.g., Active Directory or IntraCloud), defining naming conventions and usage types, assigning owners and responsible parties, and establishing access request policies and eligibility. Deletion is similarly managed through workflows that validate permissions and enforce any configured governance rules.
-
Ownership and Delegation: EmpowerID distinguishes between two key ownership roles for groups: the Responsible Party (the single business owner accountable for the group) and Access Managers (users or RBAC roles with administrative rights to manage the group). These roles are visible in both interfaces and can be modified using wizard-based workflows. They are essential for delegating management to non-administrative personnel while preserving accountability.
-
Membership Management: EmpowerID supports multiple ways to manage group membership. Users can be added or removed either manually (through guided workflows) or dynamically via RBAC membership policies. These dynamic policies allow group membership to be inherited by users based on their role, location, or other RBAC actor attributes. Membership can include both person-based and account-based objects—giving flexibility to manage service accounts, utility accounts, or other non-person entities.
-
Nested Group Management: Groups in EmpowerID can contain other groups as nested members. This is managed via a dedicated view in the Resource Admin interface, which allows adding or removing group-level members, and tracking how nesting affects membership roll-up.
-
RBAC Assignments and Permissions: EmpowerID’s RBAC engine tracks who has the ability to manage, view, or delegate a group. Each group displays its RBAC assignments, such as which users or roles have Access Manager rights, and what constraints or conditions (like time or location) may apply. These assignments can be audited and modified to reflect evolving business needs.
-
Membership Change Tracking: Every change to a group's membership—whether through EmpowerID workflows, external account store synchronization, or native system updates—is logged in a membership change log. This log includes metadata such as the time of the change, the user or process that initiated it, and whether it was a result of a native directory change or an EmpowerID policy decision. For compliance and audit purposes, this log is a key artifact.
-
IAM Shop Configuration: Groups can be published into the EmpowerID IAM Shop for self-service access requests. Administrators or delegated owners can define whether a group is requestable, what access request policy governs its approval and fulfillment, and who is eligible to request it. Eligibility can be explicitly assigned or inherited via RBAC actor relationships, such as a management role or business role and location.
-
Policy Enforcement: While the Resource Admin interface provides high-level management, policy configurations—including membership rules, attribute-based access, and approval behaviors—are typically administered through the Classic Admin interface. This ensures that only properly authorized technical personnel can manipulate the underlying logic that governs group behavior.
-
Workflow-Driven Operations: All group management operations—whether initiated through the UI or through automation—are driven by EmpowerID’s low-code/no-code workflows. These workflows can be customized to enforce business rules, require additional inputs, or present only relevant options based on the user's permissions. For example, organizations can require a Responsible Party for every group, enforce deputy assignment, or define naming conventions with multiple input fields.
EmpowerID’s approach to group management provides a unified solution for managing both the structure and governance of groups across connected systems. Whether an organization wants to empower distributed owners to manage groups directly or enforce central administrative control through policy-driven automation, EmpowerID offers the tools and flexibility to support both models securely and efficiently.
Managing Groups with the Resource Admin Interface
The Resource Admin Interface in EmpowerID is specifically designed for non-technical and semi-technical users who have delegated responsibility over groups and other resources. It provides a streamlined, guided experience for managing groups, focusing on usability and clarity while still enabling powerful administrative functions. This interface is commonly used by group owners, responsible parties, and access managers who may not be system administrators but still need to manage group memberships, visibility, eligibility, and access request settings.
Accessing and Navigating the Interface
To begin managing groups via this interface, users navigate to Identity Administration > Resource Admin, and then select the Groups option from the resource types available. The system presents a filtered list of groups that the user has rights to manage, typically based on Access Manager RBAC assignments.
A helpful feature is the ability to apply a filter such as "Owned by Me", which displays only the groups the user directly owns or has been granted delegated access to manage. From there, clicking the Details link beside any group opens the management view for that group, where users can perform a wide range of operations.
Group Overview and Management Panels
The group’s Overview page displays key summary information, including:
- Assigned Owners and Responsible Party
- Eligibility rules configured for IAM Shop visibility
- Rights and access levels, as evaluated through the risk management engine
To the left of the page, several management views are available, providing access to specific administrative functions:
-
Accounts as Members: View and manage account-based group membership. Users can add or remove accounts, including non-person entities like service or training accounts, by selecting them and executing the appropriate action.
-
Membership Change Log: A detailed audit trail that shows all changes to the group’s membership over time. It includes the action type (added/removed), timestamp, and the origin of the change—whether it came from an external account store or was processed through an EmpowerID workflow. It also shows whether the change was linked to a business request or workflow action.
-
RBAC Assignments: Displays the roles, locations, or other RBAC actors that have been assigned rights to manage the group. For example, you might see that a particular role-location pair has been assigned the Access Manager access level, giving those users delegated authority over the group.
-
Nested Group Members: Allows viewing and editing of any groups nested within the current group. Nested groups become members of the parent group and can be added or removed as needed.
-
Access Managers: Shows which users or roles are currently designated as RBAC owners. These assignments can be modified to add or remove owners directly.
-
Direct Assigned Locations: Lists any organizational locations where the group is explicitly referenced. This is useful for aligning groups with business structure and visibility policies.
-
Access Request Policy: Enables modification of the policy that governs how users can request access to the group through the IAM Shop.
While many aspects of group management are supported in the Resource Admin interface, policy configuration and system-level settings (such as ABAC policies or extension attributes) are not available here. Those are reserved for the Classic Admin interface.
Manage Group Wizard
The Manage Group Wizard is a key feature in this interface. It is a guided, wizard-based workflow that allows users to perform a wide range of management actions on a selected group. The wizard dynamically adapts to the user’s access level—administrators will see all available actions, while delegated users will only see options they are authorized to perform.
Some of the actions supported in the wizard include:
-
Add Accounts to Group: Adds individual accounts, including non-person accounts, directly to the group. This action is ideal for service or utility accounts not linked to person objects.
-
Add People to Group: Adds person objects as members with full RBAC-based permissions. This establishes a secure assignment and is typically used for standard user membership.
-
Edit Group Attributes: Modify display name (subject to naming conventions), description, notes, and advanced attributes such as extension fields. Naming conventions are still enforced automatically during this process.
-
Edit Owners and Deputies: Assign or change the group’s Responsible Party, RBAC owners (Access Managers), and deputy owners. These roles can be configured to be required or optional based on how the underlying workflow parameters are set.
-
Edit Local Function Assignments: Aligns the group with EmpowerID’s risk management framework by assigning local functions used in Segregation of Duties (SoD) and access risk calculations.
-
Edit RBAC Membership Policies: Often referred to as dynamic membership policies, these rules assign membership based on RBAC actors such as business role/location combinations or management roles. For example, you can configure a policy so that anyone in the “Standard Employee” role within “Information Technology” is automatically granted membership.
The wizard displays the resultant count of users who will be added based on the policy before applying the change, providing an opportunity to review the impact.
-
Edit IAM Shop Settings: Publish or unpublish the group in the IAM Shop, assign or modify the associated access request policy, and define eligibility. Eligibility can be assigned manually or dynamically, just like RBAC membership policies. For instance, anyone in the “All Access” management role can be marked as eligible to request the group.
-
Remove Accounts from Group: Removes members in the same guided fashion, with audit tracking and workflow-driven enforcement.
After each action, the wizard prompts the user to either continue managing the same group or switch to managing a different group, offering a seamless experience for performing multiple tasks efficiently.
Creating Groups with the Onboard Group Workflow
EmpowerID provides a guided, workflow-driven process called Onboard Group for creating new groups across connected systems. This workflow is accessible through the Resource Admin interface and is designed for both technical and delegated users who are authorized to create and configure new groups. It ensures that groups are onboarded in a controlled, consistent manner and that all required governance elements—such as ownership, requestability, and eligibility—are captured at the point of creation.
Launching the Workflow
To create a new group, users navigate to the Workflows tab in the Resource Admin interface and select Onboard Group. This launches a multi-step wizard that prompts the user to enter the necessary information to configure the group within the desired target system.
Step 1: Target Directory and Placement
The first step in the wizard is to select the target system where the group should be created. EmpowerID supports multiple connected systems such as Active Directory, IntraCloud, or other external account stores.
- If the user selects Active Directory, they are prompted to choose the Organizational Unit (OU) where the group should be placed.
- For cloud-based directories, a logical placement or location structure may be used instead.
This system-level targeting ensures that the group is created in the appropriate environment with all platform-specific characteristics intact.
Step 2: Basic Group Information
Next, the user provides:
- Group Name: A display name for the group. EmpowerID may apply naming conventions automatically, so this field is often treated as a suggested value.
- Group Usage Type: A classification label used internally by EmpowerID to organize and categorize groups. This setting is independent of the account store type and supports custom group types such as “Generic,” “Project Team,” or “Security Group.”
- Description and optional notes
The system then asks if the user wants to:
- Add permanent members to the group immediately
- Assign RBAC membership policies (dynamic rules for automatic group membership)
These options can be toggled based on the organization’s standard procedures or user preference.
Step 3: Native Group Configuration
If the group is being created in a directory like Active Directory, the user must also define the native group type. For example:
- Security Universal: A common choice for permission-based groups in AD
- Mail-enabled options: If the organization is integrated with Microsoft Exchange, users can choose whether the group should be hidden from the Global Address List (GAL) or mail-enabled
This step ensures that the group adheres to the standards of the native directory and can interact with downstream systems appropriately.
Step 4: Ownership Assignment
EmpowerID enforces ownership and accountability for all managed resources. At this step, the workflow requires assignment of:
- A Responsible Party (mandatory)—the individual who is accountable for the group and will receive recertification and ownership review tasks
- An Owner (optional)—typically the RBAC Access Manager who will be granted delegated rights to manage the group
The user selects individuals using EmpowerID’s searchable directory interface. These roles are critical for governance, as they drive auditability and access delegation downstream.
Step 5: IAM Shop Requestability
The next configuration step determines whether the group will be available in the IAM Shop for self-service access requests.
- If the group is to be requestable, the user must select an Access Request Policy, which governs how requests for access will be routed and approved.
- The user can also assign eligible assignees, which define who is allowed to request access to this group. These eligibility assignments can be:
- Explicit (e.g., specific users or roles)
- Inherited through RBAC relationships (e.g., anyone with the “All Access” management role)
There is also an option to provide IAM Shop instructions, which are displayed to users when browsing or requesting the group in the self-service portal.
Step 6: Adding Permanent Members (Optional)
If the user chose to add permanent members in the earlier step, the wizard will prompt them to select one or more accounts to be added as static members of the group. These can include both person and non-person accounts, such as:
- Named users (e.g., "Alexandra Smith")
- Utility or training accounts
This provides a quick way to bootstrap the group’s membership at creation time.
Finalization and Summary
After all configurations are set, the user submits the form. EmpowerID processes the group creation request and provides an execution summary detailing the actions that were performed. This typically includes:
- Group successfully created in the selected directory
- Access Request Policy applied
- Access Manager permissions assigned
- Permanent member(s) added
- Eligibility rules established
The summary acts as a receipt and confirmation of the onboarding process, supporting both transparency and audit tracking.
Summary
The Onboard Group workflow in EmpowerID exemplifies the platform’s low-code, policy-enforced approach to resource management. It not only simplifies group creation for authorized users but also embeds governance and compliance directly into the process. By requiring ownership, enforcing access control policies, and integrating with the IAM Shop, the workflow ensures that groups are not only created but also governed effectively from the very beginning.
Managing Groups with the Classic Admin Interface
The Classic Admin Interface in EmpowerID is designed for technical users, including system administrators and IAM professionals who require comprehensive control and visibility over group resources. Unlike the Resource Admin interface—which simplifies the experience for delegated owners—the Classic Admin interface exposes all relevant metadata, policy settings, RBAC assignments, and advanced configuration options necessary for full lifecycle governance.
This interface enables deep inspection and editing of group properties, direct manipulation of access assignments, and insight into how EmpowerID’s policy engine applies rules such as dynamic membership, risk management, visibility restrictions, and eligibility conditions. It is the preferred interface for users who are responsible for ensuring compliance, resolving access issues, or optimizing RBAC policy configurations.
Accessing the Classic Interface
To begin, users navigate to Identity Administration > Find Groups and search for the desired group. Selecting a group (e.g., Acme Banking Newsletter) opens the group’s View One page—an advanced administrative interface for managing all aspects of the group.
General Tab – Overview and Direct Editing
On the General tab, administrators can immediately view and modify several important properties:
-
Access Request Policy: This governs how access to the group is requested and approved through the IAM Shop. It can be edited directly from this screen without invoking a workflow.
-
Access Managers: These are the RBAC Owners of the group. Admins can add or remove individuals or role assignments here, determining who has delegated control over the group.
-
Responsible Party: The single accountable business owner of the group. This role is often used for recertification processes and access reviews. It too can be edited directly on this page.
-
Process and Differentiation Locations: These settings are used to align the group with specific locations in the organizational hierarchy, often for access filtering and visibility scoping.
-
Group Members: Admins can add or remove members directly from the General tab. For instance, if a user selects Jessica to be added and marks Alexandra for removal, both actions can be executed in one operation without launching a workflow.
This interface enables fast edits without the need to navigate through guided workflows, making it ideal for power users performing routine or urgent adjustments.
Advanced Tab – Deep Configuration
The Advanced tab provides access to more technical data and policy-based settings:
-
Distinguished Name: Displays the group's full path in the connected directory (e.g., the OU in Active Directory where the group resides).
-
Creation and Modification Timestamps: Essential for auditing and change tracking.
-
Extension Attributes: These are custom fields that may be used for classification, filtering, or integration with external systems.
-
Attribute-Based Membership Policies: This section shows attribute rules that determine whether users are added to the group based on values such as department, title, or location. These are key to implementing dynamic group membership.
-
Resultant Members: Displays all users who belong to the group, either through direct assignment, nested group membership, or policy-based inclusion.
-
Pre-Approved Members: Shows users who have been explicitly approved for group membership as part of delegated workflows.
Access Tab – RBAC and PBAC Policy Visibility
The Access tab provides a centralized view of how EmpowerID’s policy engines are affecting the group:
-
PBAC (Policy-Based Access Control): Displays permission levels assigned based on user attributes and eligibility rules.
-
IAM Shop Visibility: Shows the permission level for users to view or request the group in the IAM Shop.
-
RBAC Access: Provides a detailed list of users, roles, and locations that have RBAC-level assignments to the group (e.g., Access Manager, Viewer).
-
Access Risk Settings: Includes risk classifications, SoD (Segregation of Duties) rules, and violations associated with the group.
-
Function Access Reports: Displays mappings between the group and business functions used in access risk analysis.
Eligibility Tab – Self-Service Access Governance
The Eligibility tab allows administrators to view and configure who is eligible to request this group through self-service:
-
Eligibility Assignments: Define which users or RBAC actors are eligible to request access. These can be specific users, management roles, or business role-location pairs.
-
Reciprocal Eligibility: Lists other resources for which this group’s members are currently eligible, providing insight into overlapping access assignments.
These eligibility controls ensure that requestability is governed by policy, not just access level, and that only appropriate users can request the group.
Optimization and Audit Controls
Additional features in the Classic Admin interface support optimization and compliance:
-
Policy Evaluation Tools: Allow the admin to trace how a membership or access right was derived—either via direct assignment or policy inheritance.
-
Workflow-Free Edits: Unlike the Resource Admin interface, changes made here do not always trigger approval workflows. This is intentional, as many operations in this interface are meant for privileged users. If the user is authorized, the change is applied immediately; if not, it is blocked.
-
Audit Trail Support: Most edits performed here are logged for auditing purposes, but without the additional steps of approval routing unless specifically configured.
Summary
The Classic Admin interface is EmpowerID’s full-featured administrative console for managing groups. It provides unmatched depth for administrators who need complete control over group behavior, structure, membership, and governance. While it lacks the simplified, guided flows of the Resource Admin interface, it offers the speed, power, and transparency required for high-trust, high-responsibility administrative use cases.
System administrators rely on this interface to manage dynamic policies, correct membership issues, and conduct forensic audits of group access. When used in conjunction with EmpowerID’s RBAC model and policy framework, the Classic Admin interface becomes a critical tool for maintaining enterprise identity integrity and security.
Modifying Workflow Behavior
One of EmpowerID’s most powerful capabilities is its support for configuration of Low-Code workflow behavior, particularly in how it enables organizations to control and tailor the functionality of workflows such as Manage Group and Onboard Group. These workflow-driven processes are highly configurable through parameter settings that determine what inputs are required, what steps are shown, and how the workflow behaves under different conditions.
EmpowerID workflows are not static scripts—they are dynamic, reusable business processes built on EmpowerID’s visual workflow and rules engine. By exposing configuration points (known as workflow parameters), EmpowerID allows administrators to adapt workflows to meet specific governance and usability needs without modifying the core logic.
Accessing and Editing Workflow Parameters
To modify the behavior of a workflow such as Onboard Group, administrators navigate to the Low-Code/No-Code Workflows section within the administrative interface and select the Low Code Workflows menu item. From here, they can search for the workflow by name, bring up the ViewOne interface for the workflow and then browse and modify the various Workflow Configuration Parameters.
Each workflow is accompanied by a set of Request Parameters. These are the key to customizing its behavior. Examples of common parameters include:
-
OwnerIsRequired
: Determines whether the user must assign an Access Manager (RBAC Owner) during group creation. Setting this totrue
enforces the requirement; setting it tofalse
allows skipping the owner assignment step. -
ResponsiblePartyIsRequired
: Specifies whether a Responsible Party must be assigned. This is typically set totrue
to ensure every group has a defined business owner responsible for governance and recertification. -
DeputyIsRequired
: Controls whether a deputy owner must also be designated. Useful for enforcing high availability or dual oversight. -
ShowGroupUsageType
: Controls whether the Group Usage Type field is displayed during onboarding. -
ShowGroupPurposeText2
: When enabled, adds a second naming input to support compound naming conventions (e.g., using both function and location as part of the group name). -
ShowIAMShopSettings
: Determines whether the IAM Shop configuration fields (e.g., access request policy, eligibility settings) appear during the workflow. -
DefaultEmailTemplateName
,DefaultParentLocationID
, and other advanced parameters: These can be used to automate email notifications or preselect organizational contexts for the group.
Each of these parameters can be edited inline. When changes are made and saved, the services will need to be restarted to activate the new parameter values.
Customizing the Manage Group Workflow
The Manage Group workflow—used for modifying existing groups—supports a similar set of parameters. Administrators can use this flexibility to simplify or enforce certain actions during group updates. For example:
- You can hide advanced options (such as deputy management or risk assignment) from delegated users by disabling corresponding parameters.
- You can require the reassignment of ownership if the current Responsible Party is removed.
- You can enable or disable specific action steps such as editing RBAC policies or local functions, depending on the user’s role or your organizational policy.
This allows organizations to differentiate the experience between administrators and delegated owners, ensuring that non-technical users are only exposed to what they need while administrators retain full configuration access.
Practical Scenarios
This flexibility enables EmpowerID to align closely with organizational policies and maturity levels. Examples include:
- Compliance-Driven Environments: Require responsible party and deputy assignments on every new group, and enforce review of IAM Shop settings before publication.
- Delegated Administration Models: Simplify the wizard for business users by hiding technical fields, enabling just the minimum required steps for group management.
- Naming Standard Enforcement: Show additional text fields for naming convention inputs and automate concatenation behind the scenes.
- Risk-Aware Organizations: Automatically assign local function roles during onboarding for integration into the access risk management engine.
Because these settings are part of the metadata for the workflow, they can be versioned, audited, and managed without editing the workflow logic itself.
Summary
EmpowerID’s customizable workflow parameters give organizations the tools to balance governance, usability, and policy enforcement. Through editable parameters, administrators can tailor wizard-based operations like Onboard Group and Manage Group to enforce naming conventions, ensure proper ownership, control visibility of configuration options, and align the user experience with the role and responsibility of each user.
This low-code parameterization model helps organizations avoid the pitfalls of hardcoded logic or inflexible processes. Instead, EmpowerID adapts to the way you work—ensuring a consistent, secure, and efficient approach to group lifecycle management.